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(54) Method for storing data structures in memory using address pointers, and apparatus 

(57) A compiler system (190) stores a data struc- 
ture (101 , e.g., a program) to a memory (1 10) of an exe- 
cution system (100). The data structure (101) 
comprises, for example, processor instructions coded 
by compressed portions of variable lengths. The com- 
piler system (190) partitions some or all memory lines 
(1 15) of the memory (110) into P > 2 partitions, e.g., a 
and p, and writes code portions A to a first partition 
(e.g., a) and second code portions B to a second parti- 
tion (e.g., p) of an adjacent memory line (115). The 
compiler system (190) also stores addresses for some 
or all of the code portions in, for example, the memory 
(110). The addresses (260) have pointers (a and b) 
which indicate start positions j A and j B ) for portions A 
and B. Optionally, pointer magnitudes distinguish por- 
tion-to-pointer relations without the need for further 
identification bits. 
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Description 

Field of the Invention 

[0001] The present invention generally relates to computer systems and, more particularly, to methods and to sys- 
tems for storing and retrieving data structures in and from memory. 

Background of the Invention 

[0002] Embedded systems technology has become an important aspect of our daily life, starting with remote control 
devices for TV sets up to automotive engine control and navigation systems. Embedded systems development must 
take into account design constraints on size, weight, power consumption and other cost related parameters. 
[0003] The performance benefits of adopting Reduced Instruction Set Computer (RISC) architectures in embedded 
systems are well recognized in the art. RISC offer efficient and small cores. In comparison to Complete Instruction Set 
Computers (CISC), the RISCs suffers from relatively large instruction sizes and need therefore more memory space for 
the software program. 

[0004] The program, and generally any data structure, should be stored with a high code density. This can be 
achieved, for example, by off-line compressing and decompressing before execution. However, such an approach 
requires additional memory space for permanently or temporarily storing expanded instructions (e.g., a cache). Despite 
falling prices for some kind of memory (e.g., disks), memory space is still precious in embedded or similar systems. 
[0005] There is a technical task to develop storing and retrieving methods which substantially do not require additional 
space. The present invention seeks to provide methods and computer systems which mitigate or avoid these and other 
disadvantages and limitations of the prior art. 

Brief Description of the Drawings 



[0006] 




FIG. 1 


illustrates a simplified block diagram of an execution system and a compiler system in which meth- 




ods of the present invention are applied; 


FIG. 2 


illustrates a simplified block diagram of an instruction word with instruction portions and a code 




word with code portions; 


FIG. 3 


illustrates a simplified block diagram of a memory of the execution system of FIG. 1 which is virtu- 




ally partitioned according to a storage method of the present invention; 


FIG. 4 


illustrates a simplified flow chart diagram of the storage method; 


FIG. 5 


illustrates a simplified block diagram of an address used in a first embodiment of the storage 


FIGS. 6-1 to 6-3 


method; 

illustrate memory lines of the memory of FIG. 3 as they are used in the first embodiment; 


FIG. 7 


illustrates a simplified block diagram of an address used in a second embodiment of the storage 



method; 

FIGS. 8-1 to 8-12 illustrate memory lines of the memory of FIG. 3 as they are used in the second embodiment; 
FIG. 9-1 to 9-2 illustrates memory lines of the memory of FIG. 3 as they are used in a third embodiment; and 
FIG. 10 illustrates a simplified flow chart diagram of a retrieval method according to the present invention. 

Detailed Description of a Preferred Embodiment 

[0007] The present invention can be used, for example, in an embedded system which combines the advantages of 
RISC performance and compressed instruction storage. Decompressing can take place during program execution, and 
not substantially before execution. Intermediate memories (e.g., caches) are substantially not required. The present 
invention can save memory of external memories (e.g., disks) and internal memories (e.g., RAM, ROM). Also, existing 
development tools for prior art systems can be used with only minor modifications. These and other advantages of the 
present invention are explained in the following description. 

[0008] For convenience, a glossary of terms is provided prior to the claims. As used herein, the symbol @ is optionally 
used to combine reference numbers and indices when needed for explanation. 

[0009] FIG. 1 illustrates a simplified block diagram of execution system 100 (dashed frame) and compiler system 190 
in which methods of the present invention are applied. Preferably, execution system 100 comprises memory 110, data 
bus 120, converter 130, instruction bus 135, processor 140, and address bus 150. Preferably, converter 130 comprises 
P > 2 decoders (e.g., decoders 131 and 132). Memory 110 comprises a plurality of memory lines 115. Some or all of 
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memory lines 1 15 are virtually divided into P > 2 partitions (e.g., partitions a and p, details later). The partitions have 
varying lengths to accommodate different data length stored therein. In other words, partitions are defined by dynamic 
boundaries. Memory 1 10 is coupled to data bus 120 which forwards compressed code words 220 (details in FIG. 2) to 
converter 130. Converter 130 expands code words 220 and sends instruction words 210 (cf. decoding 242 in FIG. 2) to 

5 processor 140 via bus 135. Optionally, converter 130 can bypass some code words 220 and send them as instruction 
words 210 without expanding. The bypass option can be supported, for example, by an indication within code words 
220 or by additional control signals from processor 1 40. Optionally, processor 1 40 sends addresses 250 or 260 (details 
in FIGS. 5 and 7) to memory 110 via address bus 150. Codewords 220 in memory 110 can also have the function of 
addresses 250 or 260 so that address information can also go from memory 1 10 to processor 150. 

10 [0010] Optionally, busses 120, 135and 150 are bi-directional busses which can also carry instruction words 210 from 
processor 1 40 to converter 1 30, code words 220 from converter 1 30 to memory 1 1 0, or addresses 250/260 from proc- 
essor 140 to memory 110. 

[001 1 ] For the purpose of explanation, it is assumed that addresses 250/260 and data words 220 can all be stored in 
memory lines 1 15 ("data lines" and "address lines") of memory 1 10. Optionally, memory 1 10 can be divided into areas 

15 for code words 220 and for addresses 250/260. But this is not essential for the present invention. 

[0012] Compiler system 190 is illustrated as being temporarily coupled to memory 1 10 of execution system 100 via 
bus 195 (dashed) and, optionally via master memory 196 (dashed). According to a storage method (e.g., method 300) 
of the present invention, compiler system 190 stores data structure 101 (e.g., pluralities of code portions A and B) with 
compressed instructions, data and addresses in memory 110 of execution system 100. For example, portion A goes 

20 into partition a and portion B goes into partition p of an adjacent memory line 1 15@i'. Using partitions in adjacent lines 
is an important aspect of the present invention. Details for data structure 101 in memory 1 10 are explained later. Pref- 
erably, compiler system 190 is coupled to execution system 100 once before operation of execution system 100. It is 
also possible, that compiler system 1 90 writes data structure 101 first to master memory 1 96. Then, second data struc- 
ture 101 is exported to many execution systems 100. For simplicity of further explanations, master memory 196 and 

25 memory 1 1 0 should be assumed to be similar so that the term "memory 1 1 0" includes also memory 1 96. 

[001 3] According to a retrieval method of the invention (e.g., method 400), memory 1 1 0 retrieves data structure 101 
and sends data words 220 to converter 130. Preferably, the retrieval method is applied at run time of execution system 
100. Retrieving takes advantage from storing data structure 101 according to the present invention. The retrieval 
method can be considered as an inverse method in respect to the storage method. 

30 [0014] Details for the operation of data bus 120, converter 130, address bus 150, and processor 140 are not subject 
of the present invention and are therefore not explained further. It is known in the art, how to provide, for example, 
busses, decoders and central processing units (CPUs) so that those of skill in the art are able to implement these sys- 
tem elements without the need for further explanation. 

[001 5] It is an important advantage of the present invention, that the software program stored in compressed form in 
35 memory 110 need less space than a similar program stored uncompressed. 

[0016] Also, buses 120 and 150, converter 130 and processor 140 of execution processor 100 can conveniently be 
embedded into a single semiconductor substrate. The present invention is especially suitable when processor 1 40 is a 
RISC machine. 

[0017] FIG. 2 illustrates a simplified block diagram of instruction word 210 (dashed frame) with instruction portions 
40 2 1 2@$A and 212@$B and code word 220 (dashed frame) with code portions 222@A and 222@B. Instruction word 
210 can be transformed to code word 220 and vice versa. In the following, code portions 222@A and 222@B are con- 
veniently referred to as portions A and B, respectively. The division of words 210 and 220 into P = 2 portions each (A 
and B) is intended to be a non-limiting example. Those of skill in the art, are able, based on the description herein, to 
apply the present invention also for P > 2. Pluralities of code portions A and B stored in memory 1 10 form data structure 
45 101 (cf. FIG. 1). Splitting the words into portions is an advantage of the present invention and saves operation time. Par- 
allel operating devices, such as, for example decoders 1 3 1 and 1 32, need less time to transform separate portions than 
a single device would need to transform a complete word. 

[0018] In FIG. 2 an in other figures, data units 230, which are not further divided, have symbols ©, ©, ©, © or sim- 
ply O ■ Preferably, data units 230, for convenience hereinafter "bits", represent binary quantities with logical "0" and "1 " 
so values, as the case may be. But this is only a convention used for the simplicity of explanation. Those of skill in the art 
are able, based on the description herein, to use other values. The actual value (e.g., "0" or "1 ") of bits 230 is not impor- 
tant for the present invention. 

[0019] Conveniently, instruction portions 212@$A and 212@$B each have U instruction bits 231 (e.g., U = 8 bits © 
and U = 8 bits ©, respectively). The lengths V A and V B (collectively V) of code portions A and B, respectively, can vary. 
55 Portion A has V A code bits 232 (e.g., V A = 10 bits ® ) and portion B has V B code bits 232 (e.g., V B = 7 bits © ). 

[0020] The numbers V of code bits 232 are limited by a minimum number V U , N ("bounded code") and a maximum 
number V MAX , that is: 
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with the < symbol for smaller than or equal to. In the example used for explanation herein, V can assume the following 
values: 



Having equal MIN-MAX numbers for portions A and B is convenient for explanation, but not necessary for the invention. 
Optionally, the numbers can also be different, that is: 



Vamax*V bmax (2.4) 

[0021] As shown by unidirectional arrows, coding 241 transforms instruction portion 212@$A to code portion A and 
instruction portion 212@$B to code portion B. Preferably, coding is performed with compression so that V < U. This is 
convenient, but not essential for the present invention. Preferably, decoding 242, is performed by expanding in, for 
example, decoders 131 and 132. Code portion A and B are retransformed to instruction portions 212@$A and 
212@$B, respectively. 

[0022] Methods and devices for coding and decoding are well known in the art. The following reference [1] gives an 
introduction to coding and decoding: Bernard SWar: "DIGITAL COMMUNICATIONS Fundamentals and Applications", 
published by Prentice Hall, Englewood Cliffs 1998, ISBN 0-13-211939-0, especially chapter 11.6 "Source Coding" on 
pages 595-667. Therefore, persons of skill in the art are able, based on the description herein, to practice the present 
invention using known coders and decoders (e.g., in compiler system 190 and decoders 131/132 of converter 130) with- 
out the need for further explanation. Conveniently, code words 220 used in the present invention are Huffman coded 
(see subchapter 11.6.2 of [1] with a coding tree). The Huffman code is a prefix-free code (e.g., no additional bits 
between © and (2) required) and a variable length code (e.g., lengths V are different). Huffman coding (e.g., coding 
241) is assumed here only for the purpose of explaining the present invention and not intended to be limiting. 
[0023] The present invention can also be applied for encrypting or decrypting data. Preferably, the number of possible 
variations (e.g., 2( u * p ' ) of instruction bits 231 is adapted for RISC processors (e.g., processor 140). 
[0024] As explained later, compiler system 190 receives instruction words 210, performs coding 241, and writes por- 
tions A and B to adjacent memory locations in memory 100. When execution system 100 operates, converter 130 
receives portions A and B substantially simultaneously or with a time delay which can be neglected. In converter 130, 
decoder 131 of converter 130 decodes (cf. step 242) portion A to instruction portions 212@A; and decoder 132 
decodes portion B to instruction portion 212@B. Decoders 131 and 132 operate substantially in parallel and provide 
instruction word 210 substantially to processor 1 40 in a just-in-time schedule at processor run time. Extra memory (e.g. , 
cache) to store instruction words is not required. This is an important advantage of the present invention. 
[0025] FIG. 3 illustrates a simplified block diagram of memory 1 10 of execution system 100 of FIG. 1 which is virtually 
partitioned according to a storage method of the present invention. Memory 110 has memory lines 115@i with line 
index i = Oto 1-1, wherein e.g., I = 14 is not important for the invention. For simplicity, FIG. 3 illustrates only memory lines 
115@0, 115@5, 115@6, 115@10, 115@11, 115@13and 115@14. Line number I is usually much higher, e.g., I = 2 22 
« 4.000.000. Preferably, each memory line 1 15@i has J memory fields 1 18@i@j identified by line index i and position 
index j = 0 to J-1 (e.g., J = 32). A number of J B it (e.g.. Jbit = 27 ) fields are "bitfields" and store code bits 232 (cf. FIG. 
2, O symbols). A number of J TAG (e.g., J TAG = 5) fields are "tag fields" and store a line tag T(i). The numbers are related 
as: 

J BIT+ J TAG =J (3.1) 

For convenience, FIG. 3 has double-arrowed measuring lines for bit numbers. Preferably, the positions of the bit fields 
and tag fields within the range between j = 0 and j = J-1 are constant. In the example, of FIG. 3, bitfields have position 
indices between j = 0 and (J B | T - 1) (e.g., 0 and 26). Tag fields have position indices between j = (J - J TAG ) and (J-1) 
(e.g., 27 and 31) shown on the right side. 

[0026] In each memory line 1 1 5@i, line tag T(i) is a partition indicator and classifies the plurality of bit fields into P > 
2 partitions. For convenience of explanation, assume, that P has the value P = 2 (as in FIG. 2). Hereinafter, partitions 
are referred to as "partition a" a "partition P". T(i) conveniently comprises a representation for partition index j x (i). In the 
example of FIG. 3, the 5 bits of T(i) can identify any number j x (i) between 0 and J Bn -1 < 2 5 . For example, T(0) of mem- 
ory line 1 1 5@0 points to j x (0) = 1 1 and partition a comprises the 1 1 bit fields 1 1 8 from j = 0 to j = 1 0 and partition p 
comprises the 16 bit fields 118 from j = j x (0) = 11 to j = J Brr 1 = 26 . Using J Brr and position index j x (i), partition 
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lengths L„(i) and L p (i) can be defined as follows: 

L a (i) + L p (i) = J B|T (3.2) 

L a (i)=j x (') (3-3) 

Lp(i)=J B iT-L a (i) (3.4) 

In other words, L a is a complement to L p . Primed index i' which identifies memory line 1 15@i' is used accordingly. For 
convenience of explanation, boundary 119 is illustrated in each memory line 115@i between memory field 
1 18@i@Gx(i)-1) and field 1 18@i@j x (i). Boundary 1 19 is virtual and used only for convenience of explanation. In a real 
hardware implementation of memory 110 there is no need for a boundary. 

[0027] According to the invention, compiler system 190 writes portions A into partition a of memory line 115@i and 
portion B into partition p of memory line 1 1 5@i' (primed), wherein memory lines 1 15@i and 1 1 5@i' are adjacent lines. 
Portions are illustrated by partly hatched boxes (reference 222) surrounding the V A and V B code bits O ■ The term 
"adjacent" used herein is intended to include that memory lines 1 15@i and 115@i'can be single memory line 115@i = 
1 15@i' or two lines which are located at a predetermined line distance d between i' and i: 

d = | i' - i | (3.5) 

Symbols 1 1 stand for absolute values. "Adjacent" should also include, that portion A can have code bits 232 stored in 
memory line 1 15@i and further code bits 232 stored in memory line 1 15@(i+1). FIG. 3 gives an example by portion A' 
(reference 222') having first code bits 232' in partition a of line memory 1 15@13 and further code bits 232" in partition 
a of memory line 1 1 5@14. Similarly, portion B can have code bits 232 stored in memory lines 1 1 5@i' and memory lines 
1 15@(i'+1). Preferably, line distance d is one: d = 1 . This is convenient, but other values for d can also be used. For d 
= 1 , three cases ("instruction placements") can be distinguished: In case (1), both portions A and B are stored in single 
memory line 11 5@i (e.g., portions A (1) and B (1) in memory line 11 5@0); in case (2), portion A is stored in memory line 
115@i and portion B is stored in next memory line 1 15@(i+1) (e.g., A (2 > in memory line 115@5 and B' 2 ' in memory line 
1 15@6): and in case (3), portion A is stored in line i and portion B is stored in line i-1 (e.g., B (3) in memory line 1 15@10 
and A< 3 ) in memory line 1 15@1 1). Superscripts (1), (2) and (3) are used here to distinguish portions in different lines. 
In other words, portion A is stored in line i and portion B is stored in primed line i', wherein 



i' = i for case (1) common line for A and B (3.6) 

i' = i+1 for case (2) consecutive lines for A and B (3.7) 

i' = i-1 for case (3) consecutive lines for B and A (3.8) 

|i-i'|<1- (3.9) 



[0028] According to the storage method (e.g., method 300), compiler system 1 90 partitions consecutive memory lines 
1 15@i such that i and i' are within the line distance d. Using adjacent memory lines 1 15@i and 1 15@i' for storing por- 
tions A and B is convenient for retrieving and is therefore an important advantage of the present invention. According 
to the retrieving method (e.g., method 400, details later), converter 130 can read portions A and B substantially simul- 
taneously so that decoders 131 and 132 can receive portions A and B, respectively, substantially simultaneously. 
[0029] For further explanation, it is convenient to define start position j A (i) and j B (i') for portions A and B, respectively. 
A start position j A (i) within memory line 1 15@i indicates memory field 1 18@i@j (j = j A ) which stores the first code bit 
232 of portion A. The V A code bits of portion A are counted in a first direction, that is: 

fromj A (i)toG A (i)+V A -1) (3.10) 

with 0 < j A (i) and (j A (i) +V A -1) < G x (i)-1) (3.11) 

such as, for example, from the left to the right. In the example of FIG. 3, portion A* 1 ) with V A ( 1 ' = 4 code bits 232 start 
at j A = 4 and ends at j = 7. Similarly, start position j B (i') indicates memory field 118@i'@j (j = j B ) in memory line 11 5@i' 
which stores the first code bit 232 of portion B. The V B code bits are counted in a second, opposite direction, that is: 

fromj B (0to(j B (i)-V B ) (3.12) 
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withJ Bir 1 >j B (i')andG B (0-V B )>j x (i') (3.13) 

In case of portions going over 2 memory lines, V A and V B can be replaced by V' A < V A and V' B < V B which indicate the 
numbers of code bits in memory lines 1 15@i and 1 15@i', respectively. In this case, the remaining V A - V' A code bits of 
5 portion A are stored in memory line 1 15@(i+1); and the remaining V B - V' B code bits of portion B are stored in memory 
line 1 15@(i'+1). The end positions of portions A and B are conveniently not identified. It is possible to send also the 
remaining code bits (e.g., from j A +V A -1 ) to Gx" 1 ) stored in partitions a and p to converter 130. If Huffman coding is 
used, then decoders 131 and 132 can detect portion lengths V A and V B automatically. 

[0030] In order to reduce J TAG » allowable values for position index j x (i) can be limited. For example, j x (i) could be within 
10 a minimum/maximum range, that is: 

ixMIN^ixfl^ixMAX ( 314 ) 

Or, j x (i) should be an even number 

15 

jxMiN =0,2,4... (3.15) 

[0031] For convenience of explanation, and intended to give a nonlimiting example, the embodiments of the present 
invention are explained with J Brr = 31 bits, j x (i) with an allowable range of only two numbers and T(i) being a single bit. 
20 According to T(i), partition length L„(i) and L p (i) (collectively L) can assume values between a minimum value L M , N and 
a maximum value L MAX , that is 

Lmin^L<L max (3.16) 
25 e.g., L MAX = L aMAX = L pMAX = 19 bits "long" (3.17) 

e g- L M | N = L a M|N = M|N = 12 bits "short" (3.18) 
The partition lengths can be coded, for example, as follows: 

30 

L a (i) = L MAX and L p (i) = L MIN forT(i) = 0 (3.19) 
L a(0 = l max and Lpffl = I-min ° r T(i) = 1 (3.20) 

35 [0032] For further explanation it is convenient to introduce field distances X A (i) and X B (i) in memory line 1 15@i. In the 
following, index i is not written for simplicity. Field distance X A is defined as the number of bit fields 1 1 8 between portion 
A and identifier j x (at boundary 1 1 9). The X A bit fields 1 1 8 belong to partition a and do not store code bits 232 of portion 
A (e.g., fields 115@i@(j A +V A -1 ) to @(j x - 1 ) )■ The fields are illustrated to the right of portion A. Field distance X A is 
conveniently calculated as: 

40 

x A = j x -j A -v A (3- 21 ) 

In the example of memory line 1 15@1 of FIG. 3, this means: 

45 3= 11 -4-4 (3.22) 

Accordingly, field distance X B is defined as the number of bit fields 1 1 8 between portion B and identifier j x (left of portion 
B). The X B fields 1 1 8 belong to partition p and do not store code bits 232 of portion B. Field distance X B can be calcu- 
lated as: 

50 

X B=iB-i X + 1-V B ( 322 ) 

3 = 17-11 + 1-4 (example in line 1 1 5@1 (3.23) 

55 Those of skill in the art are able, based on the description herein, to calculate X A and X B in a different way, but without 
departing from the scope of the present invention. Conveniently, the X A and X B bit fields 118 of partitions a and p, 
respectively, are referred to as "partition tails". 

[0033] Memory 110 can also be described as a memory having address lines (such e.g., lines 115) for storing 
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addresses (250, 260, explained later) and data lines (e.g., lines 1 15) for storing pluralities of paired data portions (por- 
tions A and B), characterized in that 

(i) the data lines are virtually partitioned (cf. boundary 1 1 9) and store first data portions in first partitions (e.g., A in 
5 a) with first offsets (e.g., j A ) and store second data portions in second partitions (e.g., B in p) with second offsets 

(e.g. j B ), wherein the second partition is located in an adjacent data line (see cases (1), (2), (3) ); 

(ii) the address lines comprise addresses each having (i) base addresses (e.g., 255, 265, explained later) for iden- 
tifying the data lines and (ii) pointers (e.g., a and b, explained later) which indicate the first and second offsets. 

10 [0034] FIG. 4 illustrates a simplified flow chart diagram of storage method 300 of the present invention. According to 
method 300, compiler system 190 distributes portions A and B of variable lengths V A and V B to partitions a and p such 
that the partitions are located in adjacent memory lines. Preferably, method 300 is used for storing code portions A and 
B, but can also be applied to store instruction portions $A and $B. The terms "data portion" and "portion" used to 
describe method 300 are intended to include code and instruction portions or similar bit combinations. 

15 [0035] For convenience of explanation, assume that compiler system 1 90 performs method 300. However, this is not 
important for the invention. Persons of skill in the art, are able based on the description herein, to use system 100 or 
other means without the need for further explanation. 

[0036] Method 300 comprises the following steps: receiving step 310, selecting step 320, calculating tails and com- 
bination step 330, comparing step 340, moving boundary step 350, storing step 360, and, optionally, providing address 
20 step 370. 

[0037] In receiving step 310, compiler system 190 receives code portions A and B and lengths V A and V B , respec- 
tively. In selecting boundary step 320, compiler 190 chooses any boundary identifier j x . Identifier j x can be a random 
number between j = 0 and J B | T _i . Conveniently, compiler system 190 takes j x from predetermined first, second, or fur- 
ther values. For example in memory lines with J Brr = 31 bitfields 1 18, j x has either a first value of, e.g.,j x = 1 2 (partition 
25 a with 12 fields, partition p with 19 fields) or a second value of, e.g., j x = 19 (a with 19 fields, pwith 12 fields). In calcu- 
lating tails and combination step 330, compiler system 190 obtains X A and X B distances, for example according to 
above mentioned equations (3.21) to (3.24). With such a calculation, X A and X B are obtained as if portions A and B 
would have been already written into line 1 1 5. Also, compiler calculates a distance combination Y. For example, Y is the 
absolute value (| | symbols) of the difference between X A and X B , that is: 

30 

Y=|X A -X B | (4.1) 

Combination Y is an indication for the symmetry by which boundary 119 virtually divides the space between memory 
fields 1 18 which are designated for portions A and B. In comparing step 340, compiler system 190 compares combina- 
35 tion Y to predetermined reference Y M , N , such as, for example: 

(a) Y>Y MIN (4.2) 

(b) Y<Y M|N (4.3) 

40 

Preferably, reference Y M , N has a value of 

Y m ,n = 1 (4-4) 

45 but other value can also be used. The next steps depend on alternatives (a) and (b). For alternative (a) on line 341 , 
compiler system 190 stores portion A in partition a and portion B in partition p in storing step 360. Compiler can store 
portions A and Bin adjacent memory lines 115 according to cases (1), (2), and (3) which are, preferably, chosen at ran- 
dom. Also, in storing step 360, compiler system 190 writes tags T(i) and T(i') into memory lines 115. Then, optionally, 
in providing address step 370, compiler system 190 provides addresses with bases addresses and pointers a and b 

so (see FIGS. 5 and 7). The address can identify code portions A and B at any memory location (cf. jA(i), j B (i') ) within, for 
example, memory 110. This feature is especially important, when the address is part of a branch instruction and points 
to an instruction which is located far away from the branch instruction. Details for address definitions are explained later. 
For alternative (b) on line 341, in moving boundary step 350, compiler system 190 changes identifier j x . Preferably, 
compiler system 190 change j x such that Y becomes smaller and repeats (line 351) steps 350, 330 and 340 until case 

55 (a). In other words, boundary 119 is shifted until is virtually located in the center (with e.g., Y M , N = 1 allowable offset) 
between the portions. Now, compiler system 190 can repeat steps 310, 320, 330, 340, 350, 360 and 370 for further por- 
tions A and B for the same memory line 1 15 or for further memory lines 1 15. 

[0038] Preferably, in the receptions of method step 360, a number n A of portions A-| , A 2 , A 3 and so on (each with V... 
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< V A MAX ) goes into a single partition a and a number n B of portions B-| , B 2 , B 3 and so on (each with V... < V B MAX ) is 
written into a single partition p of the same memory line 115. The numbers are conveniently related as: 

n A *V MIN = n B *V MAX (4.5) 

[0039] In other words, method 300 can also be described as a method for storing a data structure (e.g., structure 101) 
in a memory (e.g., memory 1 10) comprising the steps of: 

(1) receiving a first data portion (e.g., A) having a first length (e.g., V A ) and a second data portion (e.g., B) having 
a second length (e.g., V A ) (cf. step 310); 

(2) selecting an identifier (e.g., jx) (or a "boundary") which virtually partitions a memory line (e.g., line 1 15) into a 
first partition and a second partition (e.g., a and p) (cf. step 320); 

(3) determining a first distance (e.g., X A ) between the boundary and the first portion, a second distance (e.g., X B ) 
between the boundary and the second portion, and a distance combination (e.g., Y) (cf. step 330); 

(4) comparing (cf. step 340) the combination to a predetermined reference (e.g., Y M , N ) and (a) changing the bound- 
ary (cf. step 350), determining and comparing again or (b) storing the first portion in the first partition and the sec- 
ond portion in the second partition (cf. step 360). 

[0040] In other words, method 400 can be described as a method for storing a data structure (e.g., structure 101) of 
pluralities of code portions (e.g., A, B) into pluralities of memory lines 115 which comprises the following steps: (a) pro- 
viding a first portion (e.g., portion A) and a second portion (e.g., portion B); (b) assigning a first start position (e.g., j A ) 
of the first portion within a first line (e.g., line i), and assigning a second start position of the second portion; and (c) 
writing into a first partition (e.g., a) of the first line: code bits of the first portion from the first start position in a first direc- 
tion (e.g., to the right) and writing into a second partition (e.g., p) of the first line (e.g., as p(1) ) or of a second line (e.g., 
as P(2) ): code bits of the second portion from the second start position in a second, opposite direction (e.g., to the left), 
wherein partitions are chosen such, that first and second portions are stored in adjacent lines. 
[0041] Further, method 400 can be described as a method for storing a data structure in memory with the following 
steps: (a) receiving first and second portions which in combination (e.g., A and B) belong to a single data word (e.g., 
code word 220), each code portion having a predetermined length (e.g., V); (b) virtually partitioning a first memory line 
and an second adjacent memory line into first and second partitions (e.g., a and p) by first and second partition indica- 
tor (e.g., j x (i), jx(i') defining boundaries 1 19); (c) writing the first code portions into the first partition and writing the sec- 
ond code portion into said second partition (e.g., A to a, B to p); (d) writing representations of said first partition indicator 
(e.g., tag line T(i) ) to said first memory line and of said second partition indicator to said second memory line (e.g., tag 
line T(i') ); and (e) repeating the receiving, partitioning, and writing steps for further code portions (e.g., stored in next 
lines 115). 

[0042] In the following, relations between pointers a and b, tags T(i) and T(i'), an optional indicator z, and the start 
positions j A (i) and j B (i) are explained. 

[0043] FIG. 5 illustrates a simplified block diagram of address 250 used in the first embodiment of storage method 
300 by way of example. Address 250 comprises K address bits which are distinguished as follows. Kq bits form base 
address 255 which points to memory line 1 15@i; K z bits represent cases (1), (2) and (3) by location indicator z (256); 
K a bits represent pointer a (251); and K b bits represent pointer b (252). The bit numbers are related as: 

K=K q + K z + K a + K b (5.1) 

Convenient values are, for example, K = 32, Kq = 20 to point to I < 2 20 memory lines 1 1 5@i, K z = 2 for the 3 cases, and 

K a = K b = 5 wni ch identify j x (i) by pointer a and j x (i') by pointer b, respectively. 

[0044] Indicator z can be a pair of two dedicated bits z = (z-,, z 2 ) which indicate, for example: 

z 2 = "1" :case(1) (5.2) 

z 1 = "1" and z 2 any value: case (2) (5.3) 

z 1 = "0" and z 2 any value: case (3) (5.4) 

In other words, indicator z in address 250 corresponds to tag T(i) and T(i') stored in memory 110. 
[0045] FIGS. 6-1 to 6-3 illustrate memory lines 1 15@1 and 1 15@2 of memory 1 10 of FIG. 3 as they are used for stor- 
ing portions A and B in the first embodiment of the present invention. FIG. 6-1 to FIG. 6-3 correspond to cases (1), (2) 
and (3). Lines indices 1 and 2 are used here only for convenience and can stand for any adjacent lines: in FIG. 6-1 , i = 
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i' = 1 ; in FIG. 6-2, i = 1 , i' = 2; and in FIG. 6-2 i = 2, i' = 1 . For simplicity only, portions A and B are illustrated with equal 
sizes V A and V B . But this is not important for the present invention. Boundaries 1 19@1 and 1 19@2 and tags T(1) and 
T(2) indicate the virtual partitioning of memory lines 1 15@1 and 1 15@2. Partitions a(1) and a(2) are illustrated left of 
boundaries 1 19@1 and 1 19@2, respectively; and partitions p(1) and p(2) are illustrated right of boundaries 1 19@1 and 

5 1 19@2, respectively. Left edge 113 marks the begin of partitions a(1) and a(2) and right edge 1 14 marks the begin of 
partitions p(1) and (2). For convenience, double-arrowed lines indicate e.g., J = 32 bit, J Bn - = 31 bit, L MAX = 19 bit, and 
L M , N = 12 bit. Knowing indicator [z h z 2 ) (cf. 256 in FIG. 5), pointer a identifies start position j A (i) of portion A to be in 
partition a(1) or a(2); and pointer b identifies start position j B (i ) of portion B to be in partition p(1) or p(2). For conven- 
ience, pointer a is illustrated by a dashed arrow; and pointer b is illustrated by a plain arrow. Start positions related to 

w pointers a and b as follows: 

j A (i) = a (6.1) 
j B (i') = Jb,t - b ( 62 > 

15 

In other words, pointer a goes within portion a(i) from position j = 0 (e.g., left edge 1 13) to the right (first direction) across 
a number of a code bits which do not belong to portion A; and pointer b goes within portion p(i') from position J Bn -1 
(right edge 1 14) to the left (second direction) across a number of b code bits. Pointers a and b are thereby guided by 
20 indicator (z v z 2 ) telling which lines 1 15@1 or 1 15@2 to use in cases (1), (2) or (3) for i and for i'. 

[0046] For example, possible values for pointer a are 0 ~ 1 1 when partition a has 1 2 memory fields (e.g., a(1) in FIG. 
6-1) or 0 ~ 18 when partition a has 19 memory fields (e.g., ot(2) in FIG. 6-2). The representation in the form "min ~ max" 
stand for numbers between min (including) and max (also including), that is: 

25 min < number < max. (6.3) 

number e [ min ~ max ] (6.4) 

Symbol € stands for "element of set [ ]". Similarly, pointer b can also have values 0 ~ 12 or 0 ~ 18. 
30 [0047] In general, pointer a can assume values 0 ~ L„(i)-1 and pointer b can assume values 0 ~ L|j(i)-1 , wherein the 
portion lengths are identified by tags T(1), T(2). For example, portion A could start at left edge 113 of partition a, (a = 0 
(j A = 0) ). Or, portions A could have e.g., V' A = 1 bit stored in portion <x(i) of memory line 1 15@i (e.g., a = La(i)-1 = 11) 
and the remaining V' A code bits are stored in memory line 115@(i+1). 

[0048] FIG. 6-3 also illustrates an estimation for a possible of number start position combinations. Alternatively, start 
35 positions for portions A and B can be defined in reference to two lines. For example, j' A can indicate the distance from 
left edge 113 to a start position j A (1) in line 115@1 ortoj A (2) inline 11 5@2. Similarly, j' B can indicate the distance from 
right edge 1 14 to start position j B (1) in line 1 15@1 or to j B (2) in line 1 15@2. Dashed frame 1 1 1 indicates 

2*L aM|N = 2*12 = 24 (6.5) 

40 

bit fields 1 18 in memory lines 1 15@1 and 1 15@2 (assuming "short" partitions a(1) and a(2) ). Dashed frame 1 12 indi- 
cates also 

2*L pM|N =2*12 = 24 (6.6) 

45 

bitfields 1 18 in memory lines 1 15@1 and 1 15@2 (assuming short partitions p(1) and p(2). Dashed frame 1 16 indicates 
2*(L MAX -L MAX ) = 2*(19-12) = 14 (6.7) 

so bitfields (assuming "long" a, "short" p or vice versa). Identifier j' A can be either j A (1) in line 115@1 or j A (2) in line 115 
and point to one of the 24 fields in frame 111. Similarly, identifier j' B can point to one of the 24 fields in frame 112. The 
number of combinations G'aJ'b) in frames 1 1 1 and 1 12 is 24 * 24 = 576. The number of combinations G'aJ'b) in ^me 
1 16 is calculated as 14 * 14 = 196. The total number of combinations G' A ,j' B ) is obtained as, for example, 576 + 196 = 
772. This number includes cases (1), (2), (3) and a further case if portion A and B would both be stored in line 1 15@2. 

55 [0049] In this case, the K a = 5 bits and K b = 5 bits of pointers a and b, respectively, alone would be sufficient to indicate 
any number of combinations (j' A ,j' B ) smaller then 2 to the power of (K a + ky, for example 772 < 1024. Optionally, point- 
ers a and b can form combination pointer C. Every combination Q' A ,j' B ) can be mapped to a single value of C. For exam- 
ple, pointer a forms the most significant bits (MSB) of C and pointer b forms the least significant bits (LSB) of C. For 
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example, for position j' A = 1 (portions A starting at left edge 1 13 in a(1) ) and j' B for any number 1 ~ 24 (any possible 
starts of portion B in frame 1 1 2), C can have values 1 ~ 24; for j' A = 2 and j' B any 1 ~ 24, C can have values 25 ~ 48 
and so on. Persons of skill in the art are able to implement such or a similar addressing mode (with storing and retriev- 
ing) without the need of further explanation. 

[0050] FIG. 7 illustrates a simplified block diagram of address 260 used in the second embodiment of storage method 
300 by way of example. Address 260 comprises K' address bits which are distinguished as follows. K' q bits form base 
address 265 which points to line 1 15@i; K' a bits represent pointer a (261); and rC b bits represent pointer b (262). The 
bit numbers are related as: 

K' = K' q + K' a + IC b (7.1) 

Convenient values are, for example, K' = 32, K' q = 22 to point to I < 2 22 memory lines 1 1 5@i, and K' a = K' b = 5 which 
identify j x (i) and j x (i'), respectively. 

[0051 ] Compared to the first embodiment, address 260 does not comprise indicator z. Pointers a and b are related to 
T(i) and T(i+1) and redundancies are avoided. As an advantage, address 260 (second embodiment) with, e.g. K' q = 22 
address bits can point to 4 times more memory fields 1 15@i than address 250 (first embodiment) with e.g., Kq = 20 
address bits. 

[0052] In method 300 of the second embodiment, compiler system 1 90 stores the case indication conveniently only 
in memory lines 1 15@i but not in address 260. When memory 1 10 retrieves portions A and B (cf. method 400), than 
memory 110 determines start positions j A (i) and j B (i') from T(i) and T(i') of memory 1 10 and from pointers a and b of 
address 260. 

[0053] FIGS. 8-1 to 8-12 illustrate memory lines 1 15@1 and 1 15@2 of memory 1 10 of FIG. 3 as they are conveniently 
used in the second embodiment . FIGS. 8 uses similar writing conventions as FIGS. 6. The location distinction is indi- 
cated by the combination of pointers a and b and partition indicator (e.g., (T(i) ) in memory lines 1 15@1 and 1 15@2. 
FIGS. 8-1 to 8-12 are distinguished in table 1 which illustrates possible values for pointers a and b depending on cases 
(1), (2), (3) and the a/p partitioning of lines 1 15@1 and 1 15@2. Table 1 has a "TAGS"-column subdivided for T(1) and 
T(2) and has CASE-(1)-to-(3)-columns subdivided for a and b ranges. 



Table 1 





pointers a and b depending on cas 


es and line partitioning for the second embodiment 


TAGS 


Case(1) FIGS. 8-1 to 8-4 


Case (2) FIGS. 8-5 to 8-8 


Case (3) FIGS. 8-9 to 8-12 


T(1) 


T(2) 


a 


b 


a 


b 


a 


b 




0 


0-11 


0-18 


0-11 


19-30 


12-30 


0-18 


0 


1 


0-18 


0-11 


0-18 


12-30 


19-30 


0-11 


1 


1 


0-11 


0-18 


0-11 


19-30 


19-30 


0-18 


0 


0 


0-18 


0-11 


0-18 


19-30 


19-30 


0-11 



[0054] For case (1) . pointers a and b are only used in single memory line 1 15@1 . Therefore, pointer a is within the 
limits of single partition a(1) and pointer b is within the limits of single partition p(1). Pointers a and b comply with: 

ae [0~(L aMAX -l) W be [ 0 - (Lp MAX -1 ) ] (8.1) 
a e [0~ 18] and be [0~ 18] (8.2) 



with and standing for logical conjunctive relation. Therefore, start indices are defined for memory line 1 15@i = 1 15@i' 
as: 
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j A (i) = a (8.3) 
= J n , T - b (8.4) 

Such a formulation is used for retrieving method 400. For storing method 300, start positions j A (i) and j B (i) define point- 
ers as: 

a = j A (i) (8.5) 
b = J BrT -j B (i) (8.6) 

In other words, pointer a goes from left edge 1 13 of partition a(1) across code bits which do not belong to portion A; 

and pointer b goes from right edge 1 14 of partition p(1) across code bits which do not belong to portion B. 

[0055] Pointers a and b could have maximum values of e.g., 32 (2 to the power of K' a and IC b ). For cases (2) and (3), 

a single pointer a which would start at left edge 1 13 of partition a(1) could possibly identify any start position j A (i) within 

some of partitions a(1) and a(2) of in total 1 2 + 1 9 < 32 memory fields (FIGS. 8-5 to 8-7, and FIG. 8-9 to 8-1 1). However, 

a single pointer a which would start at left edge 1 13 of partition a(1) could not cover all 19 + 19 > 32 memory fields of 

two "long" partitions a(1) and a(2) (cf. FIGS. 8-8 and 8-12). For pointer b, the problem would be similar. 

[0056] For cases (2) and (3) . the problem is avoided by starting one of the pointers at edge 1 1 3 or 1 1 4 and the other 

pointer at boundary 1 1 9@1 or 1 1 9@2. In other words, pointers a and b take a preferably short way. The information of 

boundaries 119@1 and 119@2 (i.e., T(1), T(2) ) is stored in memory lines 115 and the case distinction (2) and (3) is 

implicitly stored in pointers a and b. 

[0057] For case (2) (FIGS. 8-5 to 8-8), pointer a complies with: 

a e [0~(L oMAX -l)] (8.7) 

similar to pointer a in case (1). Pointer a defines start position j A (i) in partition a(1) as: 

Ja (i) = a (8.8) 

Pointer b is divided into a parts b-i and b 2 . The value of indicates the number of memory fields of partition (3(1) in 
which portion B is not stored. 

b = b, + b 2 (8.9) 
b, =L p (l) ifT(l)*T(2) (FIGS. 8-5 and 8-6) (8.10) 



b, =L a (l) = L p (l) ifT(l) = T(2)(FIGS.8-7and8-8) (8.11) 
j B (i) = J Brr - b 2 (in the line below) (8.12) 



[0058] In other words, pointer a goes from left edge 1 13 of partition a(1) to portion A. For unequally partitioned lines 
115@1 and 115@2 (FIGS. 8-5 and 8-6), pointer part goes from boundary 119@1 in memory line 115@1 to right 
edge 114 and pointer part b 2 goes left from right edge 1 14 to portion B. For equally partitioned lines 115@1 and 115@2 
(FIGS. 8-7 and 8-8), pointer part b-| starts at boundary 1 19@1 and goes to left edge 113, and pointer part b 2 goes in 
the same direction from right edge 1 1 4 to portion B in partition p(2). 

[0059] The value ranges for a and b given in table, do not cover all possible storage combinations. For example, in 
partition p(2) of FIG. 8-7, an area of 7 memory fields 1 1 8 is crossed out (reference 198). To avoid overlapping in the b- 
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values, b is defined for 19 ~ 30 but not defined for 12 ~ 30. A solution which avoids this limitation is given later. 
[0060] For case (3) . (FIGS. 8-9 to 8-12) pointer b similarly complies with: 

be [0- (L pMAX -l) ] (8.13) 

be [0-18] (8.14) 

Pointer b defines start position j B (1) in partition p(1) as: 

j a ( 1 ) = J B rr " b ( in the "PI* 1 " line ) (8-15) 

Pointer a is divided into a parts a-, and a 2 . The value of a 1 indicates the number of memory fields of partition a(1) in 
which portion A is not stored. 

a = a, + a 2 (8.16) 

a, =L a (l) ifT(l)*T(2)(FIGS. 8-9 and 8-10) (8.17) 

a,=L p (l) = L a (l) if T(1) = T(2)(FIGS. 8-11 and 8-12) (8.18) 

j B (2) = a 2 (in the line below) (8.19) 



[0061] In other words, pointer b goes from right edge 1 14 of partition p(1) to portion A. For unequally partitioned lines 
115@1 and 115@2 (FIGS. 8-9 and 8-10), pointer part a^ goes from boundary 119@1 in memory line 115@1 to left 
edge 113 and pointer part a 2 goes left from left edge 11 3 to portion A. For equally partitioned lines 1 15@1 and 115@2 
(FIGS. 8-1 1 and 8-12), pointer part a^ starts at boundary 1 19 and goes to right edge 114, and pointer part a 2 goes in 
the same direction from left edge 1 13 to portion A in partition a(2). 

[0062] Similarly, some fields in partition a(2) can not be addressed and are crossing out (reference 199). Ways to 
avoid this are explained later. 

[0063] Referring to the columns in table 1 , the possible values for pointers a and b can be defined in set vectors. For 
example, pointer a has values in set vector a (sub-column (1) for a, sub-column (2) for a) that is: 

a = { 0-11, 0-18, 0-11, 0-18} (8.20) 

The underscoring stands for "vector". The vector elements are sorted according to the possible partition configurations 
(e.g., configurations with two binary tags T(1), T(2) ). Accordingly, a set vector b can be defined, for example, in sub- 
column (1) for b and sub-column (3) for b) as follows: 

b = { 0- 18, 0- 11, 0- 18, 0- II } (8.21) 

Disjunct vector b' (prime marker) is defined, for example, by sub-column (2) for b, that is: 

b'= { 19 - 30, 12 - 30, 19 - 30, 19- 30 } (8.22) 

The elements in vectors b and b' are not common. Similarly, disjunct vector a' is defined, for example, by sub-column 
(3) for a, that is: 

a' = { 12- 30, 19-30, 19 -30, 19-30 } (8.23) 
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Similarly, the elements in vectors a and a' are not common. With this requirement, cases (1), (2), (3) can be distin- 
guished without the need for indication (z-|,z 2 ). According to the present invention, pointers a and b belong to disjunct 
vectors and thereby define cases (1), (2), and (3), as for example: 



Case (1): a from vector a, b from vector b (8.24) 

Case (2): a from vector a, b from vector b' (8.25) 

Case (3): a from vector a', b from vector b_ (8.25) 

A further case (4) can be identified by vectors a and b. 

[0064] Preferably, vectors a' and b' are not only disjunct to vectors a and b, respectively, but also complementary. 
Complementary vectors are defined, for example, as follows: 

a = { 0~ 11, 0~ 18, 0~ 11, 0~ 18 } (same as above) (8.26) 

a" = { 12-30, 19-30, 12 - 30, 19- 30 } (8.27) 

b ={ 0 - 18, 0 - 1 1, 0 - 18, 0 - 11 } (same as above) (8.28) 

b"= { 19 - 30, 12 - 30, 19 - 30, 12 - 30 } (8.29) 



The third element 12 ~ 30 of a" (bold) differs from the third element 19 ~ 30 of a'; and the fourth element 12-30 (bold) 
differs from the fourth element 19 ~ 30 of b'. With such a vector definition, substantially all memory fields can be 
addressed in lines 1 15@1 and 1 15@2. There is no crossing out (cf. references 198, 199) needed. 
[0065] FIGS. 9-1 and 9-2 illustrate memory lines 115@1 and 1 1 5@2 of memory 1 1 0 as they are conveniently used 
in a third embodiment of the present invention. FIG. 9-1 is a modification of FIG. 8-7 and used instead; and FIG. 9-1 is 
a modification of FIG. 8-12 and used instead. For the third embodiment, FIGS. 8-1 to 8-4 (case (1) ), FIGS. 8-5, 8-6, 8- 
8 (case (2) ) and FIGS. 8-9, 8-10 and 8-1 1 (case (3) ) are applicable without modifications. 

[0066] Table 2 illustrates a further classification of pointer values. Table 2 is similar to table 1 . For case (2), T(1) = 1 , 
T(2) = 1 (for FIG. 9-1), and for case (3), T(1) = 0, T(2) = 0 (for FIG. 9-2), the value ranges of pointers a and b are split 
into cases # and ##. Complementary pointer vectors are also obtained. 



Table 2 



pointers a and b depending on cases and line partitioning for the third embodiment 


TAGS 


Case (1)FIGS. 8-1 to 8-4 


Case (2) FIGS. 8-5, 8-6, 9-1, 8-4 


Case (3) FIGS. 8-9, 8-10, 8-11, 9- 
2 


T(1) 


T(2) 


a 


b 


a 


b 


a 


b 


1 


0 


0-11 


0 - 18 


0-11 


19-30 


12-30 


0-18 


0 


1 


0-18 


0-11 


0-18 


12-30 


19-30 


0-11 


1 


1 


0-11 


0-18 


#0- 11 ##24 
-30 


#19-30 ##0- 
11 


12-23 


0-18 


0 


0 


0-18 


0-11 


0-18 


19-30 


#19-30 ##0~ 
11 


#0~11##24~ 
30 



[0067] As illustrated in FIG. 9-1 for case (2), pointer parts a 2 , b-|, and b 2 can be defined as follows: for #: 



12/1/2009, EAST Version: 2.4.1.1 



EP 0 945 784 A1 



a, = a (left edge 1 1 3 to portion A) (9.1) 

b, = b - 19 (right edge 1 14 to portion #B, L pMAX = 19) (9.2) 
for##: 

a 2 = b (left edge 1 1 3 to portion A) (9.3) 

b 2 = a - 24 (boundary 1 1 9 to portion ##B, 2 * L a MIN = 24 ) (9.4) 

As illustrated in FIG. 9-2 for case (3), pointer a-,, a 2 , and b 2 can be similarly defined: for #: 

a, = a - 19 (left edge 113 to portion #A) (9.5) 



b, = b (right edge 1 14 to portion B) (9.6) 



for##: 

25 

a 2 = b - 24 (boundary 1 19 to portion ##A) (9.7) 
b 2 = a (right edge 1 14 to portion B) (9.8) 

30 

In other words, pointers a and b can selectively be used to indicate start positions of portions A and B, respectively, or 
vice versa, of start positions of portions B and A. 

[0068] FIG. 10 illustrates a simplified flow chart diagram of retrieval method 400 of the present invention. Retrieval 
method 400 is, preferably, performed by execution system 100 and, preferably, comprises identifying an address step 
35 410, forwarding code bits step 420, converting step 430, query step 440, jumping step 450, and incrementing base 
address step 460. 

[0069] In identifying an address step 410, processor 1 40 checks the currently processed instruction for addresses, 
for example address 250 (cf. FIG. 5) or address 260 (cf. FIG. 7). For example, the instruction (cf. instruction word 210) 
can be a jump instruction which comprises an address. Optionally, the address itself is coded and is converted by con- 
40 verter 130. This is convenient, but not essential for the invention. 

[0070] In forwarding code bits step 420, memory 1 1 0 receives base address 255 of address 250 (or base address 
265) which identifies memory line 1 15@i and 1 15@i'. Then, memory 1 10 conveniently sends all code bits 232 (cf. FIG. 
3) j = 1 to J B ir 1 fr °m memory lines 1 15@i and 1 15@i' to converter 130. The plurality of code bits 232 comprises por- 
tions A and B. 

45 [0071] In converting step 430, decoders 131 and 132 of converter 130 receives pointers a and b from address 250 
(or from address 260) and selects portions A and B from the plurality of code bits 232. Converter 1 30 applies case dis- 
tinction criteria (e.g., cases (1), (2), (3) ). For example, converter 130 receives tags T(1) and T(2) from memory lines 
1 15 and indicator z from address 250 (cf. FIG. 5, first embodiment); or, converter 130 receives tags T(1) and T(2) and 
compares the magnitudes of pointers a and b with pointer vectors (second and third embodiments) as described above. 

so Decoders 131 and 132 substantially simultaneously converts portions A and B to instruction portions 212$A and 212$B 
(cf. FIG. 2) of instruction word 210. Start positions j A (i) and j B (i) are used by converters 131 and 132, respectively, for 
example, as shift pointers, to identify portions A and B from the plurality of code bits 232. 

[0072] As illustrated by query step 440 ("JUMP ?"), the next steps depend on whether instruction word 210 has a 
jump indication ("yes"-line 441") line or does not have a jump indication ("no"-line 442"). In case of a jump instruction 
55 (line 441), memory 110 receives the new address from instruction words 210 (Jumping step 450) and system 100 con- 
tinues with forwarding step 420. In the other case (line 442), system 100 obtains the new address, preferably, by incre- 
menting the base address (incrementing base address step 460) and also continues with forwarding step 420. 
[0073] Persons of skill in the art are able, based on the description herein, to implement method 400 with hardware 
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elements of execution system 1 00 without the need for further explanation. 

[0074] Also, persons of skill in the art, based on the description herein, to apply the present invention also to memory 
line partitioning with P > 2. For such cases, the number of pointers, pointer vectors and tags can be increased. 
[0075] While the invention has been described in terms of particular structures, devices and methods, those of skill 
in the art will understand based on the description herein that it is not limited merely to such examples and that the full 
scope of the invention is properly determined by the claims that follow. 

Glossary of Terms 



@ combiner for reference numbers and indices 

A identifies code portion 

a pointer to code portion A, in the drawings with a dashed lii 

15 B identifies code portion 

b pointer to code portion B, in the drawings with a plain line 

a-|,a 2 parts of a 

bi , b 2 parts of b 

a, a', a" pointer vectors 

20 b, b', b" pointer vectors 

d line distance 

i, i' indices for memory lines 

j position index for memory field within a memory line 

j A ("). jB (O start positions of portions A and B 

25 J number of memory fields in memory line 

J B u number of bit fields in memory line 

J TAG number of tag fields in memory line 

j x (i) partition index 

K number of address bits 

30 L MAX maximum partition length 

L M | N minimum partition length 

L„(i), Lp(i), L partition lengths 

n A , n B number of portions in a single partition 

T(i) line tag for indicating j x (i) 

35 P number of portions 

U number of bits in instruction portion 

V A , V B portion lengths 

V' A , V' B number of bits which go to a single memory line 

X A , X A field distance 

40 Y combination 

z = (zi,z 2 ) indication 

$A, $B identifies instruction portions 

a, p partitions 

(1) (2) (3) as superscript, distinguish cases 



A method (300) for providing an address (260) for first and second code portions stored in memory (110), said 
method comprising the steps of: 

receiving indicators for a first length of said first code portion and for a second length of said second portion; 
receiving definitions for first and second partitions of a first memory line and for third and fourth partitions of a 
second memory line; 

receiving indications whether said first portion is stored in said first or third partition (<x(1), <x(2) ) and whether 
said second portion is stored in said second or fourth partition (P(1), p(2) ) and receiving first and second start 
positions (j A ,j B ) for said first and second portions, respectively, 
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selecting first and second pointers (261 , 262) from disjunct pointer vectors, such that magnitudes of said point- 
ers represent said first and second start positions, respectively, 

that a representation to whether said first portion is stored in said first or third partition and whether said sec- 
ond portion is stored in said second or fourth partition is represented by the pointer vectors to which said first 
and second pointers belong; and 
storing said pointers in said address. 

2. The method of claim 1 wherein said pointer vectors represent: 

a first case for which said first and second portions are stored in said first and second partitions (ct(1), p(1) ), 
respectively, 

a second case for which said first portion is stored in said first partition (a(1) ) and said second portion is stored 
in said fourth partition (0(2) ), and 

a third case for which said first portion is stored in said third partition (a(2) ) and said second portion is stored 
in said second partition (p(1) ). 

3. The method of claim 1 wherein in said selecting step, said disjunct pointer vectors are complementary vectors. 

4. A memory (110) having address lines (115) for storing addresses and data lines (115) for storing pluralities of 
paired data portions (101), the memory characterized in that 

the data lines are virtually partitioned and store first data portions in first partitions (a) with first offsets (j A ) and 
store second data portions in second partitions ((3) with second offsets Q B ), wherein the second partition is 
located in an adjacent data line; 

the address lines comprise addresses each having (i) base addresses (255, 256) for identifying the data lines 
and (ii) pointers (251 , 252, 261 , 262) which indicate the first and second offsets. 

5. The memory of claim 4 wherein the addresses (250) further comprise indicators (256) for distinguishing whether 
the first and second data portions are stored in identical data lines or in consecutive data lines. 

6. The memory of claim 4 wherein magnitudes of the pointers also indicate whether 

(1) the first data portion and the second data portion are stored together in a single data line 

(2) the first data portion is stored in a first data line and the second data portion is stored in a second data line, 

(3) the second data portion is stored in a first data line and the first data portion is stored in a second data line. 

7. The memory of claim 4 wherein the address lines each have 5 fields (251 , 261) for storing a first pointer and 5 fields 
(252, 262) for storing a second pointer, and wherein the data lines each have 31 bitfields (1 15) partitioned into par- 
titions which with 1 2 bits fields and 1 9 bit fields. 

8. The memory of claim 4 further comprising a converter (130) which 

(i) receives bits (232) stored in the data line among them the data portions, 

(ii) receives the pointers to identify the data portions and 

(iii) which substantially simultaneously converts first and second data portions to instructions. 

9. The memory of claim 4 wherein the data lines comprise indications for lengths (T(i) ) of first and second partitions. 

1 0. The memory of claim 4 wherein pointers belong to disjunct pointer vectors and thereby distinguish storage location 
of first and second data portions. 

11. The memory of claim 4 wherein the pointers belong to complementary pointer vectors and thereby distinguish stor- 
age locations of first and second data portions. 
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